\chapter{Conclusion}
\label{chap:conclusion}
%\addcontentsline{toc}{chapter}{Conclusion}

We set out to test our hypothesis that it is possible to write a computer game in which the agents' decision making is purely based on readily available planning systems. We also tried to integrate the same tools into the development process in the form of level design.

While using planners in agent control we had to realize how completely different approach these tools require than other, more traditional agent systems; this however does not mean that they would be incapable of filling the role. Their strength is in the rational decision making they were built to perform. As opposed to finite state machines or decision trees a planner requires only a goal and a set of possible actions. They are not dependent on the capabilities of the programmer who wrote the agent and they seamlessly adapt even to changing environments.

On the other hand compared to the above mentioned tools planners also have a characteristic weakness: poor scalability.
With increasing layout sizes the length of the planning process increases exponentially and quickly reaches a point where letting the player wait any longer is not a viable option. Another manifestation of pure scalability is the increasing visibility of suboptimal action sequences.

The developer has to be aware of these conditions (our largest game levels are included to demonstrate them) and if required, take actions by either introducing a multi-layered planning system, or trying to reduce the set of details that is sent to the planner.

Finally we have to conclude that while planning certainly has its own pitfalls, we managed to apply it nearly seamlessly into the gameplay (see chapter~\ref{chap:agentControl}).

In our type of game, designing levels is strongly connected to the field of agent control, so we met all the advantages and pitfalls of planners we mentioned above. The ability to produce a full action sequence for the burglar agent in a single planning run that contains all the actions he intends to execute greatly simplified our work. On the other hand generating traps for a larger layout easily takes several minutes. In that time interval a human designer with a good editor tool can manage the same job, probably even better, more convincing one.

We also have to note that inherent characteristics of our tested planning systems prevent us from passing several important decisions directly to the planner. Large part of our work on the level creator tool was finding translations of such decisions into planner problems. For example these systems can't solve two excluding goals simultaneously in a Minimax fashion. This simple fact in our early experiments resulted in  burglars running into the hands of guards.

To summarize, our expectations were partially fulfilled. We found it possible to use planners in the design process, however our results are not on equal level with the work of a human.

The list of considered planning tools that truly fulfilled our requirements is only 4 entries long and to our knowledge they are available only on UNIX-type systems.

The user response we received was positive, all of the players reported that they enjoyed exploring their possibilities in the game environment. Unfortunately we had no long term testers, so we don't know how long would their interest sustain. We should not forget that this program is only a demonstration of a concept. To be truly successful it would need many further improvements, some of which (advised by the testers) can be found in the Feature requests section. 



%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Future works}
\label{sec:futureWorks}

Here we mention some features that we would have liked to implement but limitations in time and human resources prevented us from doing so.

While working on the agent behavior the most interesting question we met were connected to the replanning rules of the game characters. It would be a great addition to the program if we could improve the plan optimizing methods of our agents (described ins sections~\ref{sec:whenTochangePlans} and \ref{sec:timeRequirements}). We implemented and experienced only with a well selected group of methods that we considered to be the most promising, but there are still others to test out (for example more direct integration of PDDL actions into our game world with direct representation of their preconditions and results). 

In the gameplay we used the performance measure of traditional planning systems to measure the quality of our action sequences. It would be interesting to define a performance measure to human-like agents where for example exploring an area and finding alternative solutions to a problem would be a virtue as opposed to our measurements.

While developing agent control we also stumbled upon the problem of controlling multiple agents in cooperation. Managing a group of guards to effectively surround the burglar who is supported by the player would be a great challenge, but unfortunately we touched the problem only marginally and ended up using agents that were hardly aware of each other. The task however is still interesting and probably could be a good ground of a future thesis.

Using planners to partially generate a game level is a nice feature, but we could have followed automatization a step further. Several commercial games use random generated levels. It is a long standing and well developed practice, and for this very reason it wasn't interesting to us. But used in cooperation with our level creation methods it would leave hardly any work for the human designer but some final touches. The developer could select the general properties of the layout, then let it be generated and forwarded to our program that places the challenges on it.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Alternative problem definition}

The following section is strongly based on a technical report titled \emph{``Burglar-Game: Planning Used In A Level Design And During A Gameplay''} \cite{burglarICAPSsubmission} written in cooperation with Rudolf Kadlec.

In our problem definition a player typically needs several actions to neutralize a trap, but on the other side whole series of traps might be solved by a single clever move.

We could propose an alternative, more restricted, definition of $F'$ than we did in chapter~\ref{chap:problemDefinition}.

First we define an alternative to $H$.
$H'(a, P, S_{burglar}) = S'_{burglar}$ 
models a situation where the player executes an action $a \in A$ and due to the effects of $a$ the burglar can no longer follow its current plan $P$, hence he stops and updates its world state with previously unknown effects of $a$, which results in the new state $S'_{burglar}$.

Let for $n \in  \mathbb{N}, n \ge 1$ $F'$ fulfills the following condition:
\begin{gather}
S_{burglar}\in F'(S_{real}, n) \equiv (\ref{eq:believable})~\wedge \nonumber \\ 
\exists a  \in A: H'(a, P, S_{burglar}) = S'_{burglar}~\wedge \label{eq:userAct2} \\
S'_{burglar} \in F'(S_{real}, n-1)~\wedge \label{eq:recursive} \\
\forall k < n - 1 :  S'_{burglar} \notin F'(S_{real}, k)~\label{eq:minimal}
\end{gather}

For $n = 0$ we define $F'$ as: 
\begin{gather}
S_{burglar} \in F'(S_{real}, 0) \iff  \nonumber \\ 
\exists P: \neg flawed(P, S_{burglar}) \wedge \neg flawed(P, S_{real}) \label{eq:ok2}
\end{gather}

This definition shares the Condition~\ref{eq:believable} with definition of $F$. Then it requires that there is single user's action that makes the burglar stop and update its world state to $S'_{burglar}$ (Condition~\ref{eq:userAct2}); given $S'_{burglar}$, the burglar can choose a plan with $n - 1$ pitfalls (Condition~\ref{eq:recursive}), but not less (Condition~\ref{eq:minimal}). When the recursion reaches its end we require that the burglar can choose a plan that is solving the goal not only in his belief base, but also in the real state of the world (Condition~\ref{eq:ok2}).

If we compare $F$ and $F'$, $F$ requires the player to make at least one action, whereas $F'$ requires full sequence of $n$ player's actions. On the other hand $F$, is easier to compute and leaves more freedom of alternative solutions. In the future we want to at least attempt implementing $F'$, but so far our generator uses the definition $F$.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Feature requests}

The features requested by the testers (in chapter~\ref{chap:playerResponses}) for possible future implementation fall into three categories: \emph{interface, gameplay experience}, and \emph{additional features}.

On the \emph{interface} it would be a useful to use a full featured game engine that would implement sub-windows in a standard manner. This would enable us to make the cursor change seamlessly between the windows and the cursor on the game area would disappear when moved over a notification. With such an environment there would be no need to explicitly click on the Cancel button in the context menu.

The following features in the field of \emph{game experience} seemed nice, and strongly advised in a full fledged commercial game, but in our proof of concept implementation seemed to be less relevant, so they were left for future improvements: When the game is in motion, the viewpoint should center on the burglar, and follow him so the player could always follow the most relevant part of the game area; the possibility to zoom in and out would also allow a better overview of the game events. In the current version of the game some details (for example the context of the agents' inventory or the keys that unlock certain objects) are only visible through the status line (section~\ref{sec:statusLine}). It would be nice to introduce visible clues representing such details. Finally waiting for the replanning process might be nerve wrecking to the user; it would be nice to at least hint the maximal required time they need to wait for the game to continue.

Into the last category we have improvements that would make the game more interesting and longer lasting fun to the player, for example an increased set of actions the user is capable to execute would add variability. The most interesting idea was throwing a banana peal that would be cheaper than dazing a guard. It would work as a kind of a landmine that is ``dangerous'' to both the burglar and the guards and would carry the additional challenge to predict which exact tile would an agent use to get to a certain place.
Finally adding a high score list to the menu would help to compare game results between multiple players.







